When a mobile communications device, such as mobile telephone, is used outside the coverage of its home network, it is referred to as a roaming device. Generally, a roaming device can be used to make calls via a visited network as if it were within the coverage of its home network. This is possible because the visited and home networks are arranged to allow such calls and to co-operate with call management. One protocol used to enable such co-operation is the Customised Applications for Mobile Enhanced Logic (CAMEL) protocol, which enables a full range of Intelligent Network (IN) services from a home network to be accessed via a visited network. One such service is making calls on a visited network from a prepaid mobile device.
However, some visited networks are not enabled with the CAMEL technology. In these networks, prepaid calling by visiting mobile devices can to be carried out using a different mechanism that makes use of a technology called Unstructured Supplementary Service Data (USSD). USSD is built into the Global System for Mobile Communications (GSM) standard. USSD commands are routed back to the home mobile network's Home Location Register (HLR), so as to provide access to IN services from the home network to a roaming mobile device.
The Home Location Register (HLR) is a database that contains mobile subscriber information for the home network's subscriber base. HLR subscriber information includes the International Mobile Subscriber Identity (IMSI), service subscription information, location information, service restrictions and supplementary services information. The HLR handles signalling transactions with both Mobile Switching Centres (MSCs) and Visited Location Registers (VLRs), which either request information from the HLR or update the information contained within the HLR. The HLR also initiates transactions with VLRs to complete incoming calls and to update subscriber data.
When the HLR receives a USSD call instruction from a roaming prepaid mobile device, the HLR forwards the instruction to a network element called a USSD Call Back Gateway (CBGW). The CBGW is arranged set up roaming prepaid calls in a particular way (detailed below) which enables the current prepaid credit for the mobile device to be properly monitored against the instructed call so that it can be accurately charged. The CBGW uses a network element called a Service Control Platform (SCP) in the control and charging of such calls.
In response to a USSD instruction from a prepaid mobile device (A) to set up a call to a called party (B), the following steps are carried out:
The CBGW first sets up a call to the mobile device A and the MSC triggers the SCP to monitor this first call leg;
The prepaid account balance for the mobile device is then checked and if it is sufficient, call processing continues;
When the mobile device A is reached, a call is set up to the called party B. When the call to the called party is answered, the two calls are bridged and the
MSC triggers the SCP to monitor this second call leg;
The call legs are then monitored by the SCP to collect data to enable the calls to be charged appropriately.
In order to charge the call the SCP needs: the telephone numbers of both the mobile device (A) and the called party (B); the physical network location of the mobile device (A); and the call duration of the call to B. However, because the location of the mobile device (A) is only sent in the initial set-up command (Initial Detection Point (IDP)) for the call leg to the mobile device (A), this location data is not available to the SCP. Furthermore, the duration of the call to the called party (B) can only be recorded accurately by monitoring the second call leg. This is because the first call leg to the mobile device A is connected before the call to B is connected. Therefore, the call to A will be longer than the call to B and only the duration of the call to B will provide an accurate record of the duration for the bridged call. Therefore, in order to collect the data for charging the call, it is necessary to correlate the monitoring data for both legs of the call. In order to achieve this, identifiers need to be attached to the monitoring data for each call leg and the monitored data then passed to the same SCP for correlation. These restrictions have significant implementation and running costs.